BCI NET 2

home *** CD-ROM | disk | FTP | other *** search

/ BCI NET 2 / BCI NET 2.iso / archives / networking / misc / envoy20fixinfo.lha / Envoy20FixedBugs

Wrap

Text File | 1995-02-05 | 32.3 KB | 554 lines

Information on the Enhancements and Fixed Bugs in Envoy 2.0 =========================================================== There were no small amount of questions on what has changed from Envoy 1.6 to the current Envoy 2.0 release. To answer these questions we decided to make our informal "FixedBugs" file publically available. Not only on the Envoy distribution disk, but also separately. This file has been created during the development process of Envoy 2.0. So be careful: ************************************************************************ * * * DISCLAIMER * * * * THIS SOFTWARE AND INFORMATION IS PROVIDED "AS IS". * * NO REPRESENTATIONS OR WARRANTIES ARE MADE WITH RESPECT TO THE * * ACCURACY, RELIABILITY, PERFORMANCE, CURRENTNESS, OR OPERATION * * OF THIS SOFTWARE AND INFORMATION, AND ALL USE IS AT YOUR OWN RISK. * * NEITHER COMMODORE NOR THE AUTHORS ASSUME ANY RESPONSIBILITY OR * * LIABILITY WHATSOEVER WITH RESPECT TO YOUR USE OF THIS SOFTWARE * * AND INFORMATION. * * * ************************************************************************ While Envoy is of course not freely redistributable at all, you may distribute this informational file in unmodified form only if you want to. We sincerely hope you do so, as of course any further development of Envoy 2.0 depends on its commercial success. If you want information on how to upgrade to, or obtain Envoy 2.0, please send email to <info@iam.com>. Heinz Wrobel & Dale L. Larson Intangible Assets Manufacturing /*------------------------------------------------------------------------*/ This is an internal, informal unedited list of fixed bugs, changes and beta notes during the 2.0 development process. It is provided as a courtesy to developers and other power-users. Please do not ask us questions about this list -- if you don't have a problem to report with 2.0 you don't have a problem. Please also realize that most software has lists of fixed bugs at least this large -- they just usually aren't made public. The large list doesn't mean that the software was unreliable or not useful for most users in previous versions. Hopefully more software vendors will be more open, since openness provides more confidence to sophisticated users than it does scare people about the number of small bugs in typical software. We no longer have a list of known bugs. If we knew about them, we'd have fixed 'em. Fixed bugs and changes since Envoy 1.6a ======================================= [Really important behaviour changes are marked with '!!'] - Crash on aborting examines (C:LIST, CTRL-C). - FindService() returning garbage error codes. - GetHostName() appending LocalHost to the passed buffer for a NULL enitity passed. - Crashes in HostRequestA(). Lousy GUI code. Fixed for now. Should be replaced. - Repaired half a ton of "cast" bugs. Lots of code used inappropriate and sometimes really destructive casts. - NIPCBuffer trashing on local ACTION_READ and ACTION_WRITE. - endless retry on security reject which in essence hangs the client and loads the line. - filesystem.service used to open after one failed open if nipc.library was available, even if the other libraries needed were not. Net result ==> GURU! - ACTION_SET_FILE_SIZE should work now. - hanging lock on security failure when trying to enter a directory. - fs server left locks on failing mount requests for non existing volumes. - on mount fs server reported "doesn't exist" when it in fact rejected the user. - server had serious problems with handling requester suppression on a mount. - ACTION_FH_FROM_LOCK works now. - fcconfig deleted temporary ".info" file manually. It now uses DeleteDiskObject(). - fsconfig did not really fit onto a 640x200 topaz 8 WB. - The fs code and the fs prefs code duplicated many structures and defines which should have been defined in one place only to avoid compatibility breaks. Fixed now. Referencing includes across directories is not nice but a lot better than duplicating their contents arbitrarily. I need to do something about nipc, too. - Cleaned out obsolete intuition identifiers where I found them. - Groups prefs has now a better login. - About menus added to the filesystem prefs editors. - An english locale text for the nipc prefs was too long. Fixed. - Small kludge added to nipc.library to have Envoy 1.65 behaviour on the S2 CopyFromBuffer callback. Envoy 1.65 always returned success on this callback no matter what. Hmm. DO NOT DEPEND ON THIS! - Missing Permit() in FindEntity() code could potentially have stopped the system. - nipc S2 code could leave buffer lying around on low memory. - nipc S2 code did not necessarily queue ARP requests again when the remote side came back into service. - internal nipc S2 packet counters for internal statistics were not handled correctly. Doesn't matter for the user though. This was more a cosmetic fix. - nipc UDP closed connection via Forbid() protection while the list was otherwise semaphore protected. - nipc ARP buffer entry timeout value was wrong by a factor of 10. - nipc doesn't depend on services.library internals anymore. services.library V40(!) has special private access functions now. services manager uses these for locking now, too. - CreateEntityA() made the entity available before it was fully initialised. If this was done just at the "right" time, nipc.library would crash or do other strange things. - nipc RDP made an active connection available on open before having set up all data needed. - gross bugs in nipc RDP handling. The headerlength was not set according to RFC908 and on dataless "flag" packets the wrong sequence number was used! Actually I am not sure if RDP works as described in RFC908/1151 at all. The code looks more like "we do it not quite like they do it" which really is annoying. - dataless RDP packets updated the sequence number of the last ack'ed packet to the current one even if there was no ack! - nipc RDP data acceptance via PacketIn() had major problems: - If a needed packet in sequence did not arrive, it would continue to queue even redundant packets until death. - In two places it had search algorithms with an O(n^2) like brute force approach to the problem. Hmpfh. - it ack'ed segments but did not tell the timeout code that those segments were acked. So the timeout code sent another ack. I rewrote this completely. No reasonable way to fix it without throwing it out. - nipc RDP code would in some cases either dereference NULL pointers or other invalid list pointers, access closed (non existing!) connections, or send spurious resets to the other side with garbage sequence numbers. - On closing nipc RDP connections in the listening state, the RDP code sent a reset to some undiscovered country. - nipc RDP resets were not necessarily obeyed. - While checking on some nipc stuff I found that NIPCConfig would really barf on you if you tried to use the Realm configuration screen. As it turned out, someone used "mlh_Tail" instead of "mlh_TailPred" for walking a list. - nipc AMP code cleared out all the RDP flags when it had been signaled on an available transmit window. '!' was used for inverting a bit mask rather than '~' in three places scattered in BeginTransaction() and ReplyTransaction()! A sure killer IMHO. The same bug was in DeleteEntity() in handling entity flags. Just wondering: How did nipc work at all? ;^) :-( - nipc RDP will now flush still pending writes when they are acknowledged, not only on a timeout run after it has timed out! - On startup nipc will do better checking of any sana2 device it tries to open. This fixes e.g. an open amoksana.device with no HW connected. - If a sana2 device goes into "failure mode" and barfs on any and all requests for some reason, nipc.library would hog the CPU and in effect lock the system. Error handling tries to be smarter now, even though there is no true general solution to the problem. This should help in most cases, though. - FindEntity() messed with an entity after releasing the entity list semaphore. Tiny window, but a window. - password hook in the login requester fixed. Now it is possible to delete a password that is too long and retype it. - printer prefs and Users are now localised. - Strange double click behaviour in Filesystem Imports ListView fixed. - fixed potential holes in nipc sana 2 code that could have messed up sana 2 addresses with a bit count that is not a multipe of eight. - nipc sana 2 code did not clear allocated IORequest memory in all cases. This could have caused strange flag settings etc. !! - nipc ARP will now be used for all HW types, not just for !! ethernet connections. This is an incompatible change but fixes !! the HW address vs. IP address dependency problems. !! - If the user chose defaults for IP and ARP type in the network !! configuration for a device, he will get ethernet values 2048 and 2054 !! unless ARCNET is used. Then 240 and 241 are used as defaults !! in nipc.library. While this is not a good solution at all as it !! doesn't take into account the actual HW available, it will at !! least give reproducible results compared to the "ignore the !! checkmarks and take whatever we have" type of behaviour. - There is a major conceptual problem with RDP sequence number wrap around. This always has and still does completely confuse the RDP code and will in effect make the RDP connection affected unusable and probably flood the net with packet retransmits that are never correctly acknowledged. I am in the process of doing something about this, but this is a _very_ tricky subject. Hopefully my rework of sequence number handling works. This needs more testing. - With my RDP rework I added a new bug affecting the start up of a connection. For fixing this bug I did some heavy RDP debugging. So RDP connections should work a lot better now. Especially starting up an RDP connection should be now as fast as it used to be again. Again, the new release might be incompatible to previous buggy releases. Sorry for the inconvenience. We are now at nipc.library 40.18. - Changed the printspool.service naming convention for jobs from "t:job%ld" to "T:EnvoyPrintJob_%ld" to avoid any conflicts. - Services Configuration should no longer leave filelocks or library opens hanging! It will also default to "/Services" now as directory for adding services (it is based in Configurations!). This should help poor B. J. User somewhat. - Back to the filesystem. ACTION_READ_LINK returned DOSTRUE and ERROR_ACTION_NOT_KNOWN for some strange reason. Fixed. This shouldn't have been a problem anyway as ReadLink() should only be called if ERROR_IS_SOFT_LINK has been returned by the FS, which of course cannot happen. - Found a hole in internal restarts of ExAll type requests. Packets were added to the head of the main FS packet port without any protection at all! - ACTION_MAKE_LINK will now work for hard links. This might e.g. help DUUCP users with a networked news tree. - I decided to finally try it: Record locking should work now. This needs more testing though for reliability. - ACTION_DELETE_OBJECT may take a lot longer for large files than pretty much any other packet. So the default timeout of 6 seconds was not enough and even though the packet succeeded, the network transaction timed out. I bumped the timeout to 18 seconds for a delete. This stuff shouldn't be done via a single transaction, but it is not at all easy to rewrite! Bumping the timeout is not a solution but it'll make the situation at least a lot better for most users. - Really nasty bug on reconnect of a broken network mount. The client passed the full server path of the object in question without the server drive specifier. This could lead to write files popping up in strange places suddenly and read files not to reconnect. Same problem fixed for locks. - ACTION_READ/ACTION_WRITE could still leave buffers lying around on failure. Should be fixed now. - ACTION_READ/ACTION_WRITE would pretty much garble the client seek position on network failure or partial R/W failure. Now a bona fide attempt is done to keep the seek position correct. This might still fail of course, but this is better than not doing anything at all about it. - While an ACTION_READ/ACTION_WRITE is pending all incoming packets for this file handle are saved and queued again after the R/W is complete. The packets were requeued in reversed order and without sufficient list protection. - I found a reproducible case where after a reconnect the client was accessing the root of the mounted server drive where the network volume is located, and not the root of the network volume. - The server did not clean up exall handling for locks discarded on a dead mount. - The client/server had an internal concept of a -1 lock which represented the current server directory on reconnect. No code used this feature for anything useful and it messed up reconnections with volume relative paths. I took it out. Reconnect works volume base relative now. - ACTION_EXAMINE_ALL was commented out on the client side. Why? Because it was totally and absolutely f...ouled up in many subtle ways on both the client and server side. It should work now. Please test this and all the bells and whistles like eac_MatchFunc in detail. Why I did all this work? Because EXAMINE_ALL and all the other examine functions share common code. So I had to fix it. - ACTION_EXAMINE_NEXT could be ended prematurely, pulling out the rug under the client while doing this. - The server tried to filter filenames in the examine calls even if there was no buffer space set up. - Did some autodoc typo fixes in nipc.library. - Tiny change in nipc.library's buffer handling. What is externally visible as AppendNIPCBuff() will now move the list of buffer entries in one piece instead of entry after entry. This saves some CPU time. I improved this on the way as I found a possible cause for an enforcer hit in low memory situations. Found this due to a bug report on nipc enforcer hits that were actually caused by the fs code. - With the fs update, I introduced a bug in R/W buffer handling that could cause enforcer hits in nipc.library under certain network failure situations. Fixed, hopefully. - Interesting enough, I cultivated a bug in exall handling when redoing the exall stuff. The matchstring was passed to the server to filter entries. While this is in theory a neat idea by the C= guys to save on the actual transfer, it doesn't work as I know now. Preparsed patterns are not portable between different dos.library versions. Now all the filtering is done on the client side. This is unfortunately much less efficient. - Another bug was in filtering of exall entries on the client side. It did not remove entries correctly in all cases. - The sana2 code in nipc.library could "forget" to requeue packets for ARP under certain conditions. It also queued read packets for devices known to be offline which is totally useless and hogs the CPU. - Slight rework of R/W packet handling to be on the safe side. I _think_ I found the hole causing spurious enforcer hits via nipc.library once in a while, but I am not sure yet. - "Network Configuration" will no longer force the realm checkboxes set, just because there are entries in the realm lists. This makes it possible to turn off a realmserver without loosing the entered prefs data. - It should be possible now to use the RETURN key in the "Network Configuration" "Host Configuration" panel to hop from gadget to gadget just like with all the other panels. - There is still a bug in the RDP code when a packet sequence number wrap around occurs. I found this based on a hunch regarding the "overnight hanging bug". This bug in effect breaks the connection. I have started to investigate and fix this, and as a result the new nipc.library will once again be absolutely incompatible to previous versions. Sorry. A side effect of my work for a fix is that some fields are now 32 bit aligned which should help on anything >=68020, i.e. >= A1200. - Sequence number wraparound should be ok now. Finally. - Fixed a few holes in the RDP code where a task waiting on RDP permission to send stuff would sleep forever. When this happened due to the sequence number wrap around bug, this connection would effectively hang. This should explain and fix the "overnight hangs" for good. I hope there isn't more of this. We are now at nipc.library 40.24. - Note that nipc will not use trans_Timeout for local transactions currently. So a local entity connection will hang if the destination hangs. The source has no chance to recover. I feel that this is a bug (which is currently hard to fix). What do you think? COMMENTS ARE WELCOME! - The server could show erratic behaviour if you sent paths longer than 128 characters to ACTION_LOCATE/DELETE_OBJECT and ACTION_CREATE_DIR. - ACTION_SET_DATE would return garbage results on a security failure. - ACTION_CHANGE_MODE was flaky with filehandles before. Should work now. - fs server locked a semaphore a few lines to late. No problem with normal use, but still a bug. - On cleaning up dead mounts, the server left a lock lying around. - The client was flaky with timeout settings on reconnect. This could hang a reconnect. - Unlocking NULL locks is not nice, but should be regarded as ok. This is now the case. - Believe it or not, I found another nipc bug. If you deleted a public entity that still had connections pending, it would be silenced as far as possible, but not be made private. This would lead to enforcer hits if a remote side tried to enumerate entities. As a side effect of my fix, FindEntity() will now behave according to spec and only find local entites if they were created with ENT_Public, just like with remote entities. We are now up to nipc.library 40.25. How many revision will there be? - ACTION_DELETE_OBJECT will now run async on the server. It should no longer block server activity for other clients until the delete is done. The client will get a response when the delete is done, but the server is not locked up for other clients in the meantime. - The client is now a little better about doing at least one retry with a prolonged timeout itself before putting up a requester. So timeout requesters will come later now. - EFS should behave _much_better_ now with server drives having RMS. It used to barf in many ways, now it should handle this rather gracefully and hopefully do the right thing in all cases. As this needs truly tons of testing, I hesitate to say that Envoy has RMS now. While the mounts on the client turn up as public entities now, it won't make any sense for a user to FindEntity() them. They are public only to let the server be able to contact them in majik wayz. Please try this with CDx: and DFx: and whatever you got. Note that RMS does not carry across machines. You can't export a volume in df0:, get locks on it on the client, move the disk physically to the client's disk drives and expect it to be recognized. !! - A BEHAVIOUR CHANGE of fs exports. An export with an empty export !! name used to get the clients device mount name. Now it will get !! the true volume name of the servers volume. This makes much more !! sense and an empty name is now the preferred setting for !! exporting a DOS device with RMS. Actually it is probably !! reasonable to say a few things about RMS name handling and !! reconnect behaviour now. As described above the client used to !! have the same name for the volume node as for the client's !! device node if no export name was specified on the server. This !! was not logical, as both the export and import prefs listed the !! server's export path (typically a device name) in this case. In !! this case the client can make much more use of the server's !! volume name. All this does not affect name use of the client at !! all, as of course the device node is still there and any !! reference to that name will now go via the device node instead !! of the volume node. Nothing is lost. The client just has !! additional information available via the correct volume node. !! RMS and reconnect are related to the above. If an export name is !! configured on the server, it will be only used on a mount of an !! inserted volume or a reconnect (which is in effect a remount). !! If no name is configured the true volume name will be used. For !! any disk change, only the true volume nname will be used. Why? !! because having different active volumes with all the same name !! doesn't make much sense. So there is one simple rule now: If you !! export a drive/device with RMS, don't specify an export name. - the server should no longer work with garbage guid/uid's on low memory situations. - I got tired of rebooting, so now the server supports file notification on its prefs file in ENV:. One can change the export configuration on the fly now. The Services Manager will also try to reload its configuration now if it has been changed. Note that this cannot (and probably should not) be done easily for nipc due to how all the stuff works. - Added a "Use" button to the fs export prefs and appropriate menu headers to select env: or envarc: values. Default is empty. - Services Prefs behaved strange when using the "Last Saved" menu. It appended the stuff to the current list of services. - Notification should be working now. Some special notes about this, though: a) Any action done through EFS that should cause a notification of the client, will cause one (Guru Book!). The ROM fs and RAM handler don't do it that way. b) Any action done through the server fs will cause a notification if that fs supports notification for the action. Needed to get notifed of other's accesses. c) As a result, any action done through EFS will cause 1 notification event if only EFS supports it, and 2 notification events if both EFS and the server fs support it. While two events can be annoying at times, they are better than none at all. I have no way to tell which actions on the server side fs will cause a notification by that fs and which won't. Please test this with both signal and message notification and whatever flags there are, and with reconnect! - The login requester password hook was a pain. I removed editing restrictions now to make it work. For users that get lost in typing in dots this means, they probably better kill the contents and retype in some cases. - The printer server should now process spooled client files in 8k chunks instead of 1k chunks. This _might_ help efficiency. - ACTION_WRITE_PROTECT is supported now. It will leave the server untouched and do only client side write protection. - Another change for ACTION_DELETE_OBJECT. While it doesn't block server operation anymore for other mounts, all packets for the client mount of the delete will be queued until the delete is done and processed afterwards. Why? To guarantee sequential behaviour in packet processing. Note: PLEASE TEST THIS! Maybe by sending of an async delete packet and sending other packets before the reply comes in. I don't trust my own tests at all here. This stuff is tricky. - String gadgets in Login/Host requester will be activated on window activation. - String gadget contents in Host requester will now be used even if it wasn't deactivated by TAB/ENTER. - I decided not to do anything about the string gadgets in Network Configuration, Users, and Groups. This doesn't hurt too much and would require some rewrite. - I think I found the "split file on reconnect" bug. Finally. A baselock for a path of a file to open was assumed to be the parent lock of the file itself. So any path specs in the file name got lost on the way which messed up paths for reconnect. - As Dale correctly said, the printer stuff is FUBAR. Unless there are any error reports, I probably won't touch it again. it needs to be rethought and rewritten from scratch. - Due to all the changes outlined above, I decided to call this Envoy 2.0, not 1.8. - Services Configuration has now "Enabled:" again as english label for the checkbox. For <V39 systems, I removed the display of the currently selected service under the listview. There was no reasonable way to get it to look nice on < 3.0 and >= 3.0. This type of "bug fix" has been done to some other prefs editors previously by C=. Probably for the same reason. It doesn't hurt the user interface though. While doing this I found that a) memory was left lying around when adding a bad service b) an asl requester was freed twice while another wasn't freed at all on exit. Automatic reboot included. We are now at 37.13. - Enforcer hit in nipc.library fixed. I introduced this bug with my fixes for 40.25. Now we are at 40.26. - A minor problem with notification in the fs server. Notification was not done for the parent directory of the modified object. Notification for objects referenced with a lock and an empty file name could have been flaky. This should be ok now. I did not mention one other thing before: Notification should theoretically be done on all the hard links of the modified object, too. If you think about it hard, you will realise that this is not possible. This is not a bug. Anyway, the server is now up to 40.29. - This is embarassing. I left in debugging code that delayed a notification setup for > 1 second. Server is now at 40.30. - The AmiCDRom filesystem doesn't seem to set up its struct Resident correctly. This caused hits on volume insertion. I put a kludge into the fs server to compensate for this problem. Now at 40.31. - The client sets the DiskType in the volume nodes now. This should help "Filesystem Imports" to decide on already mounted mounts. Now at 40.41. - Minor typo fixes in some doc files and minor german locale update. - Filesystem Imports complained on empty drives even if the mount was ok. Fixed. It should be a lot better about determining which drives are already mounted, too. The original code had "crashy" tendencies for removable media and did not take device mounts into account. Now at 40.9. - Filesystem Imports will now check only active Envoy mounts to see if they are already mounted. Inactive mounts should be left alone for sure, now. Now at 40.10 - The efs client did some filehandle init it should not have done. Now at 40.42. - The efs client could give enforcer hits if someone did an UnLock() right after an Examine()/ExNext() in just the right timing. A lock was freed twice and invalid memory way referenced in that case. Also freeing a ZERO lock could probably result in unusual behaviour. As all the lock handling code turned out to have some perfectly valid, but obscure areas from the simple readability point of view, I did some beautification work in addition to fixing things. And while this is very ugly behaviour of any application, efs should now be robust against "copied" locks. This last thing is mainly a paranoia fix triggered by my research on the exnext problem which started this. Now at 40.43. - Found some places where lock pointers were set up without a check for the BPTR to be ZERO. This was always ugly and is deadly now. The efs client is up to 40.44 now. - nipc should no longer try to write to sana 2 devices which are definitely known to be offline. This should be cosmetic though. I am still not clear on what is causing problems with ppp.device. But maybe this reduction of io helps finding the actual problem. Now at 40.27. - After some thought I decided to modify the sana 2 device init in nipc to complain loud on any problems. I assume now that the user wants those devices she specified in Network Configuration to work well. Previously only a failure to open a device at all caused an requester to pop up. Now any "fatal" error which will prohibit nipc from setting up and using a device will generate a requester. This should reduce the "doesn't do anything after boot" problems without user notification by about 100%. And it should help fix bugs as you will get to see an error number. nipc.library is now at 40.28. - The EFS client returned ERROR_WRITE_PROTECTED instead of ERROR_DISK_WRITE_PROTECTED on an active ACTION_WRITE_PROTECT. This is fixed now and the EFS client is now at 40.45. - Bumped some versions to allow for a decent HWGRCS version freeze for release. I was unfortunately lazy sometimes. No change in functionality at all. Just a recompile with a new version number. filesystem.service: 40.32 Filesystem Imports: 40.11 Filesystem Exports: 40.9 nipc.library: 40.29 envoy.library: 37.21 services.library: 40.2 !! - I have a hunch concerning the ppp.device problem. It is now !! possible to disable ARP by setting the ARP type to the IP type. !! It counts as unsupported hack, though. I am not sure it will stay !! that way. This does not affect compatibility as it is a normally !! illegal combination of values anyway. Maybe ARP was the problem. !! If this was truly the problem, we need to either document this !! way to turn off ARP or find a more intuitive way to do this !! for the user. Hmm. What about an ARP type of 0 to turn off ARP? !! Hmm. Let's wait on feedback. nipc.library is now at 40.30. - The list of services was not correctly locked by nipc during an inquiry. This could lead to overwritten memory, crashes or similarly nasty things when the list changed at just the right time while an inquiry was active. nipc.library is now at 40.31. - The host requester in envoy.library had rather high stack usage. This should be better now. It could also mess up the system if you specified to many matchtags. This should be better, too. Now at 37.23. - Filesystem Imports had rather high stack usage, too. It also allocated a VisualInfo and never ever freed it. Now at 40.12. !! - Ok, this is it. The IMHO last change before releasing Envoy 2.0. !! The official way to turn ARP off is to set the ARP type to 0 !! now. nipc.library is now at 40.32. !! Not all sana 2 drivers can transmit ARP packets. ARP is !! usually useful on Ethernet, and maybe on ARCNET or amoknet. !! For other sana 2 devices, refer to the respective documentation. *** End Of Text ***